Related GitHub Issue

Closes: #524

Note: Issue #524 is awaiting maintainer approval/assignment. The "Issue Linked" checklist item is left unchecked per project policy until the issue is approved.

Description

When Execa spawns a command with shell: true, Node forks a shell process which in turn forks the actual command. Killing only the shell PID leaves its children running -- the shell exits but does not propagate the signal to its children, so processes like sleep 30 keep going until they finish naturally.

How the fix works:

• On POSIX, add detached: true to the Execa options. This causes the OS to place the shell and all of its descendants into a new process group, with the shell as the group leader. On Windows, detached: true is omitted -- it causes a console-window flash that windowsHide cannot reliably suppress, and it is not needed since taskkill /F /T handles tree-kill without a detached process.
• On abort(), branch on platform:
  • POSIX (macOS/Linux): send process.kill(-pid, "SIGKILL") (negative PID = kill the entire process group). This atomically signals every process in the group -- the shell, its children, grandchildren, and any background jobs -- with no race condition.
  • Windows: call spawnSync("taskkill", ["/F", "/T", "/PID", pid]). The /T flag kills the full process tree (shell + all descendants). process.kill(-pid) is POSIX-only and not available on Win32.
• On abort, emit { exitCode: 137, signalName: "SIGKILL" } instead of exitCode: 0, so the UI running-indicator dot correctly turns red (consistent with the integrated terminal path).
• Remove the ps-tree dependency and the associated 100 ms delayed PID-tracking logic, which was the previous (incomplete) attempt at this fix.

Reviewers should note:

• The detached: true option is required on POSIX for process.kill(-pid, ...) to work. Without it the subprocess is in the parent's process group and a negative-PID kill would affect unrelated processes.
• A fallback to subprocess.kill("SIGKILL") is retained for the edge case where the primary kill throws (e.g. ESRCH -- process already exited).
• The VSCode integrated terminal path (TerminalProcess) is not changed by this PR. It sends Ctrl+C via sendText and cannot reach background jobs inside the PTY. This is a known limitation documented in the test results file.
• Windows taskkill path has not been manually tested by the author -- unit tests covering the mocked spawnSync call are present (platform-guarded, skipped on non-win32). Community verification welcome.

Test Procedure

Automated tests (18 passing, 2 skipped on non-win32):

cd src && npx vitest run integrations/terminal/__tests__/ExecaTerminalProcess.spec.ts

New tests cover:

• Process group kill via negative PID (POSIX)
• Windows process tree kill via taskkill /F /T /PID (skipped on non-win32)
• Fallback to subprocess.kill when primary kill throws (both platforms)
• No-op when PID is not yet set
• exitCode: 137 emitted on abort
• Race condition: stream throws before aborted flag is checked

Manual test (macOS/Linux):

1. Ask Zoo Code to run: sleep 30
2. Click Stop before the command finishes
3. In a separate terminal: ps aux | grep sleep | grep -v grep
4. Expected: empty output (process is dead)

Tested successfully: sleep 30, nested sh -c 'sh -c "sleep 30"', loop with sleeps.

Note: background jobs via sh -c 'sleep 15 & sleep 15 & sleep 15 & wait' are killed correctly when using the inline terminal, but are not killed when using integrated terminal due to fundamental limitations with the integrated terminal path.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue -- issue [BUG] Clicking Stop does not kill child processes spawned by the terminal -- shell exits but children keep running #524 is filed but awaiting maintainer approval/assignment.
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

No UI changes beyond the running-indicator dot color correction (green -> red on abort).

Documentation Updates

• No documentation updates are required.

Additional Notes

• ps-tree and @types/ps-tree are removed from src/package.json as they are no longer used.
• detached: true is set only on POSIX (where it is required for process.kill(-pid, "SIGKILL") to target only the spawned process group, not the Node.js parent process). On Windows it is skipped: detached: true triggers a console-window flash that windowsHide cannot reliably suppress due to a race in the Windows CreateProcess API.
• On Windows, taskkill /F /T /PID achieves the equivalent tree-kill. taskkill.exe is a Win32 system binary available on all Windows versions since XP, invoked directly via spawnSync (bypasses the user's configured shell). Note: taskkill /T walks the PPID tree rather than targeting a kernel-tracked group, so it is susceptible to orphaned descendants if an intermediate process exits before Stop is clicked. This is strictly less racy than the previous ps-tree-based approach, which was identically vulnerable but introduced an extra 100 ms delay that widened the race window. A fully race-free Windows solution would require a helper utility to assign processes to a Windows Job Object (which the kernel tracks independently of the PPID chain), but that is out of scope for this PR.